The present invention relates to virtual data Processing machines and, in particular, to a method and apparatus for enabling such virtual data Processing machines to keep their state across invocations, to amortize initialization and runtime costs, to avoid garbage collection and Process termination and to provide greater application security, isolation and availability.
Virtual machines are created within a Process for the purpose of loading and running an application. As is known, a xe2x80x9cProcessxe2x80x9d isolates resources that are allocated to a particular program during runtime and prevents multiple programs from interfering with each other""s execution. At the termination of execution of an application program, the entire Process is torn down.
As virtual machine applications increase, it is desirable to retain the virtual machine so as to enable it to execute a next application program. This can save the expensive costs of Process tear down and start up. For example, prior art computer systems may need to execute between 5 million and 40 million lines of code to reestablish a virtual machine and a Process. Having a long running, reusable virtual machine also saves the cost of class linking, loading and initialization which are also expensive in terms of use of computational facilities. Avoiding the creation of a virtual machine environment, per application, also increases the volume and throughput of applications a system can manage.
Currently, virtual machines are uniProcess and begin and end when the application completes. The prior art has suggested various ways to keep the state of a virtual machine in existence. One suggested solution is to maintain a pool of virtual machine Processes. Another is to xe2x80x9ccheck pointxe2x80x9d a virtual machine""s state (i.e., to retain for subsequent use a copy of all machine values that the machine has set). A further solution is to maintain a pool of virtual machines and to send objects created in one virtual machine to the xe2x80x9cheapxe2x80x9d (i.e., an allocated area of memory) of another virtual machine.
Maintaining a pool of virtual machines does not diminish an initialization path length of a virtual machine. Scheduling of application programs in a previously created virtual machine hides the path length from a client request, but does not reduce class linking, loading or initialization requirements nor does it obviate a need to bring up and tear down a Process for each application.
Check pointing a virtual machine""s state and applying it to new Processes requires pointer and offset readjustments that are costly in path length and may not be possible in systems where a range of addresses a Process will command cannot be guaranteed.
Reuse of a same virtual machine Process for multiple applications does not guarantee a clean heap nor a writable static area of memory (i.e., predefined fields with assigned integer values) for each application that runs consecutively in the virtual machine.
Maintaining a pool of virtual machines and xe2x80x9cfunction shippingxe2x80x9d an application program to a correct virtual machine or sending the correct object to the virtual machine (where the application is running) requires a cache coherency scheme, incurs extra overhead and possibly network flows to pass the application or object. Moreover, this procedure does not guarantee that the memory space in each virtual machine is devoid of values left by previous applications.
Accordingly, it is an object of the present invention to provide a long running, reusable, extensible, virtual machine to run application programs.
Another object of the present invention is to obviate the need to tear down and bring up a new virtual machine to insure that dynamic or static memory values set by a previous application program are no longer present.
Yet another object of the present invention is to initialize a virtual machine once and to reuse this initialization state across subsequent virtual machine Processes.
A further object of the present invention is to load, link, verify, and compile a class once and to reuse this class data across subsequent virtual machine Processes.
A still further object of the present invention is to invoke the initialization methods of a class once and to reuse this class data across subsequent virtual machine Processes.
Yet another object of the present invention is to be able to run multiple applications in a long running virtual machine and have each application isolated from each other, increasing the availability of the virtual machine.
Still another object of the present invention is to separate a virtual machine""s state into different heaps: private and shared, which enable application isolation, more efficient garbage collection and an ability to extend the virtual machine""s runtime.
Another object of the present invention is to obviate the need for garbage collection on a virtual machine""s private state.
An architecture for a virtual machine which can be persistent through multiple applications includes a shared heap where requisite runtime classes to bring the virtual machine into a xe2x80x98readyxe2x80x99 mode are loaded, linked, verified, initialized and compiled. Subsequent virtual machines are started and use the contents of the shared heap where the necessary system classes have already been loaded and initialized. Application lasses are loaded into the shared heap, allowing subsequent applications to reuse these classes without the cost of reloading. relinking, reverifying and recompiling the classes. Application programs create their objects in xe2x80x9cprivate heapsxe2x80x9d. At the end of execution of the application, the private heap is reinitialized. No garbage collection (i.e., a method for finding unused memory) need occur on the private heap.
Static initializers are methods that create predefined values (hereafter xe2x80x9cstatic valuesxe2x80x9d)  that are maintained in a persistent area of the private heap. This persistent area is is not reset to a common value, but rather is reset to its initial values, between execution of applications. This action obviates the need to terminate the virtual machine Process. If applications xe2x80x9cmisbehavexe2x80x9d (i.e. open or create external Process related resources, e.g., threads, file descriptors, etc.), the virtual machine Process is terminated to insure complete clean up of those resources. However, the shared heap is not deleted and can be used by subsequent virtual machines. These subsequent virtual machines save the overhead of reloading, relinking, recompiling, reverifying any of the classes needed for runtime initialization or any of the application classes that have been used previously.
This architecture has the effect of a long running, reusable, virtual machine, because classes, once loaded, need not be loaded or initialized again.